Information and content distribution systems are used to provide information and content to a plurality of end systems. For example, in video-on-demand applications, media content has been provided to and utilized by satellite/cable television subscribers. Typically, subscribers can view selectable media content at their television via the subscriber's set-top-box (STB). In this case, the selected media content or video program is sent from the program center to the set-top-box via the cable or satellite network. Play lists can be implemented in video-on-demand applications to schedule video programming and advertisements.
Similarly, in advertising, it is becoming popular to provide in-store retail media content to customers. This new advertising medium generally uses broadcast distribution as its primary means of content presentation. Recently, retailers and managers of public spaces have populated their stores and public spaces with increasing numbers of video display systems primarily for advertising. In such video display systems, content is distributed by a server to one or more set-top-boxes associated with a respective display or a respective group of displays. Retailers typically use the displays to present their current offerings or sale information or the like. In contrast, managers of the public spaces sell time and space on their video displays to advertisers at a national or local level, with knowledge that large numbers of potential consumers will see the video presentation. Again, in systems such as the in-store retail advertising systems, play lists can be implemented to schedule media content including clips of current offerings, sale information, or advertisements.
In all these systems, many situations can arise that require dynamic changes to the play list to meet business objectives. For example, it may be necessary to substitute a specific media file, or set of media files, for other such files; or it may be necessary to avoid or defer playing a specific media file or set of media files; or it may even be necessary to insert a specific media file or set of media files in addition to the content already in the play list. Building a new play list at a centralized network operations center may not be a viable solution in these exemplary situations. This is especially true when changes are desired at a pace which is not permitted by the centralized network operations center or when play list changes are permitted to be made under control of the local entity without a requirement to coordinate with the centralized network operations center.
Media play lists can be generated by many different languages or technologies. The Synchronized Multimedia Integration Language (SMIL) is a popular play list generation technology used for media playback scripting that enables simple authoring of interactive audiovisual presentations. SMIL is based on XML and is, by nature, a static means of scripting playback. These play lists are static in that they are created prior to playback starting and they remain the same during playback. That is, once created, the play list does not change until rebuilt or reloaded. The play list is a script that is followed by the playback software to determine the layout, sequence, and timing of the presented media. It will be understood herein that the term “play list” is analogous and even identical to the term “play sheet” or “play list sheet” all of which may be used interchangeably herein without any loss or change in meaning.
SMIL is typically used for “rich media”/multimedia presentations which integrate streaming audio and video with images, text, or any other media type. It is an easy-to-learn HTML-like language in which many presentations can be written using a simple text-editor. SMIL pages are sometimes static and sometimes generated dynamically, the way that web pages are built. In this context, when it is said that SMIL pages are sometimes “generated dynamically”, it means that the play list is built on demand or just in time for use by reloading or rebuilding the play list; wherein the actual play list that is generated becomes a static entity passed to the playback software for presentation of the media. Unfortunately, any reloading of a SMIL play sheet results in a visible full screen transition between the first SMIL play sheet existing prior to reloading and the newly reloaded SMIL play sheet. This reloading causes the media presentation to lack seamlessness.
Often there is just a desire to add an element or graphic overlay to, or remove an element or graphic overlay from, a sequence of images or videos that have been already defined. For example, in a retail advertising environment, there may exist a desire to present a seamless video presentation to shoppers with no full screen transitions through a black screen or the like. As already discussed above, loading a new SMIL play sheet will interrupt the playback with some type of transition and result in a presentation that is not a seamless presentation of media. In addition, there are times where it is desired to change the presentation on some or all screens in a retail environment to play the same media without any distracting transition that might cut off a video clip mid-way through playback. But, the generation and display of a new SMIL play sheet generates exactly such undesirable and distracting transitions because of the need to reload the SMIL sheet or page that has been changed.
The latest SMIL specification purports to accommodate dynamic changes in media while lacking any details about how such an accommodation might be achieved and implemented. Of course, this is a consistent practice for standards documents that define a high level of functionality or operational capability without giving any details about implementing a design to achieve the required functionality or operational capability. To with, on the W3C website (i.e., w3.org) for the standards document from the period around Jan. 15, 2008, it is stated that, “[u]sing the DOM level 2 methods of SMIL, an application can change the values of attributes and add and delete elements in a running SMIL presentation. Whether such editing is allowed is implementation dependent, although a profile may require support. In terms from the SMIL 3.0 Animation chapter, changing the value of an attribute through a DOM method changes the base value of the attribute. If animations are included in the profile, any animations on the same attribute build upon this changed base value. The presentation value which results from applying an animation is not visible through the DOM. The presentation effect of other changes through the DOM to a document while it is being played back is implementation-dependent.” From this excerpt, although it is clear that the transition problem has been recognized from reloading the play sheet in SMIL, it is even clearer that no solution has been provided by the standards developers and contributors.
No mechanism for making these change requests is specified in the SMIL specification. Even web technology can use embedded links in a file, but it does not provide a means to allow an external controller to specify changes asynchronously. While user actions on normal web pages may result in running a JavaScript code that causes the page to connect to a remote server and to obtain changes, no such techniques are available for either the web or SMIL implementations that allow an external processor to send instructions asynchronously to modify a running play list at runtime.
Thus it is clear that there are two problems in the prior art. In one instance, when a SMIL play sheet is loaded and executing in a player or via playback software, there is no standard way to force that player to load a new SMIL play sheet due to changes to the play sheet. Moreover, even if there were a potential means to do this, the reload operation of the SMIL play sheet would result in an undesirable video transition that would negatively affect the viewing experience.